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Abstract 

With  declining  defense  budgets,  the  U.S.  Department  of  Defense  (DoD)  has  been  forced  to 
re-examine  its  mission,  capabilities,  and  processes.  As  the  DoD  wrestles  with  reexamination 
of  its  priorities,  so  too  does  the  acquisition  community,  and  particularly  those  in  the  project 
management  community  have  an  important  role  to  play. 

The  Honorable  Frank  Kendall,  USD(AT&L),  has  championed  the  role  the  acquisition 
community  can  play  in  the  effort  to  streamline,  adapt,  and  innovate  the  way  the  DoD  plans 
and  carries  out  acquisitions.  Kendall’s  Better  Buying  Power  effort — currently  in  its  third 
instantiation — illustrates  many  of  the  key  areas  that  the  acquisition  and  project  management 
communities  must  address.  Closely  aligned  with  Better  Buying  Power’s  goals  is  the  need  to 
implement  a  system  of  project  management  that  integrates  the  three  foundational  pillars  of 
project  management — scope,  cost,  and  time — with  the  ability  to  adapt  to  a  changing 
environment  that  meets  customer  requirements.  Space  and  Naval  Warfare  Systems  Center 
Pacific  (SSC  Pacific)  is  addressing  this  challenge  by  adopting  and  refining  the  CMMI  Model, 
and  building  the  tenets  of  integrated  project  management  (IPM)  into  project  planning  and 
execution.  This  paper  illustrates  the  guidelines  for  a  project  manager  under  this  model. 

Introduction 

There  is  no  such  thing  as  “the  typical  project.”  No  two  projects  ever  seem  to  be  the 
same — similar,  yes,  but  they  all  have  a  uniqueness  about  them.  Developing  a  plan  to 
execute  a  project  can  be  an  arduous  event  but  well  worth  the  time  and  effort  when  the 
project  plan  lays  the  foundation  for  project  execution.  Working  the  details  by  incorporating 
the  integrated  project  management  (IPM)  process  allows  for  transparency  and  positive 
control  throughout  the  life  cycle  of  the  project.  The  intent  of  this  paper  is  to  identify  how 
there  is  a  natural  occurrence  of  IPM  when  utilizing  the  sound  project  management  practices 
that  comprise  the  five  overarching  process  areas  outlined  by  the  Project  Management 
Institute  (PM I):  Project  Initiation,  Project  Planning,  Project  Execution,  Project  Monitoring  and 
Control,  and  Project  Close  Out.  A  major  emphasis  is  placed  on  the  project  planning  phase 
and,  as  we  note  later,  its  level  of  detail  that  directly  affects  IPM  and  the  execution, 
monitoring,  and  control  of  the  project. 

Project  planning,  although  certainly  not  the  sexiest  part  of  a  project  manager’s  job,  is 
a  critical  component  to  the  success  of  the  project  and  is  the  hallmark  for  cost,  schedule,  and 
technical  performance  execution.  But  here’s  the  rub — as  a  project  manager,  we  often  feel 
that  as  soon  as  we  have  a  project  assignment  and  we  have  funding  on  hand,  we  are  already 
behind  schedule.  In  today’s  l-need-it-now  environment,  the  moment  the  project  is  funded, 
stakeholders  are  already  expecting  results.  One  of  the  first  processes  in  the  life  of  a  project 
is  stakeholder  identification,  and  it  is  critical  to  have  this  understanding  from  the  earliest  part 
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of  the  project.  Managing  stakeholder  expectations  is  critical  to  the  success  of  the  project, 
and  we  must  communicate  the  need  to  take  the  time  for  upfront  planning;  if  performed 
properly,  it  will  help  drive  the  efficiency  and  effectiveness  of  project  execution.  This  really 
allows  us  to  take  the  first  step  in  preparing  to  launch  the  new  project  and  establishing  the 
project  charter. 

So  how  do  we  define  what  a  project  is?  Sometimes  I  think  this  is  an  age-old 
question,  and  the  definition  changes  from  organization  to  organization;  however,  the  Project 
Management  Institute  (PMI;  2013)  defines  a  project  as  “a  temporary  endeavor  undertaken  to 
create  a  unique  product,  service  or  result.”  This  would  indicate  a  definitive  beginning  and 
end  to  achieve  a  specific  outcome  of  which  a  unique  product,  service,  or  result  is  achieved. 
However,  some  projects  have  a  definite  end  before  achieving  completion  due  to  constraints 
that  preclude  completion,  be  it  funding,  realization  the  outcome  cannot  be  met,  and  so  forth. 
Key  components  that  must  be  considered  are  the  most  basic  of  a  project:  time  (schedule), 
cost  (budget)  and  technical  performance  (product/service/event),  which  form  the  core 
components  (or  pillars)  of  what  we  are  embarked  upon  when  taking  on  a  project.  This  brings 
us  to  the  crux  of  looking  at  project  management  with  a  slightly  different  filter;  taking  a  look  at 
how  we  can  fully  appreciate  the  development  of  true  I  PM,  and  the  criticality  of  sequencing 
the  five  process  areas  that  align  to  the  project  life  cycle. 

PMI  (2013)  states, 

Project  Integration  Management  includes  the  processes  and  activities  needed 
to  identify,  define,  combine,  unify,  and  coordinate  the  various  processes  and 
activities  with  the  project  management  process  groups.  In  the  project 
management  context,  integration  includes  characteristics  of  unification, 
consolidation,  communication  and  integrative  actions  that  are  crucial  to 
controlled  project  execution  through  completion,  successfully  managing 
stakeholder  expectations  and  meeting  requirements. 

Under  the  Capability  Maturity  Model  Integration  (CMMI),  IPM  is  defined  as  “the  integrated 
process  for  the  project  management  which  is  tailored  from  the  organization’s  standard 
process  of  project  management”  (Khare,  2013).  We  can  take  a  look  at  some  very  specific 
areas  that  directly  impact  the  project  where  their  efforts  are  so  intertwined  it  is 
incomprehensible  to  not  identify  them  as  integrated  processes.  However,  before  we  jump 
directly  into  this,  we  need  to  have  an  overarching  understanding  and  take  a  look  at  the 
project  architecture,  or  process  flow  if  you  will,  to  better  comprehend  how  and  why  an 
integrated  process  is  so  very  important.  Taking  a  look  at  the  five  process  groups,  we  show 
how  the  project  life  cycle  is  directly  impacted  as  we  apply  appropriate  project  management 
rigor  based  on  where  a  project  has  progressed  through  its  life  cycle.  As  seen  in  Figure  1 ,  the 
interrelated  aspects  of  this  interaction  and  the  cyclical  efforts  continue  throughout  the 
project’s  life  cycle. 
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Figure  1.  Interrelationship  of  a  Project’s  Management  Process  Areas  and  Life 

Cycle 

So  what  does  this  really  mean  to  the  project  manager  that  wants  to  get  the  job  done 
and  meet  the  customers’  expectations?  It  provides  a  guideline  for  the  project  manager  to 
establish  a  completely  integrated  project  plan  that  will  allow  proper  execution  across  the  life 
cycle  of  the  project.  We  look  at  what  I  call  the  “6  Pillars  of  Project  Management”  through  all 
process  phase  areas.  We  spend  a  significant  amount  of  time  in  the  planning  phase  simply 
due  to  the  fact  that  without  proper  and  complete  planning,  it  is  nearly  impossible  to  establish 
a  truly  integrated  project  management  plan  (IPMP),  let  alone  execute  and  effectively  monitor 
and  control  the  project  with  a  sense  of  realization. 

It  is  consistently  stated  that  a  project  manager  must  always  be  concerned  with  the 
execution  of  cost,  schedule,  and  technical  performance,  also  known  as  the  three 
foundational  pillars  of  project  management:  scope,  cost,  and  time.  They  are  so 
fundamentally  connected  in  project  management  that  they  must  be  continuously  monitored 
and  measured  for  execution  to  ensure  the  project  is  intact  and  meeting  its  planned  delivery. 
By  implementing  IPM,  the  project  manager  is  inherently  recognizing  the  interactions 
between  these  three  foundational  pillars  and  the  processes  that  work  together  to  ensure  that 
project  execution  is  on  time  and  within  budget  while  meeting  the  technical  performance  as 
laid  out  in  the  requirements.  It  is  important  to  realize  that  IPM  is  implemented  across  the  life 
cycle,  from  project  initiation  through  closeout.  In  order  for  the  project  manager  to  ensure  the 
objective  of  the  project  execution  is  being  met,  a  plan  must  be  in  place  that  is  forward 
looking.  The  threats  and  opportunities  to  the  project  known  as  risk  should  be  identified,  and 
the  potential  cost  of  those  risks  must  be  calculated  should  the  need  arise  to  implement  a 
mitigation  strategy  or  a  contingency  plan.  Furthermore,  the  project  manager  must  have  a 
means  to  measure  the  success  of  the  project  as  it  is  being  executed  throughout  the  life 
cycle.  This  could  include  gate  reviews,  testing,  verification  of  requirements,  and  validating 
that  what  is  being  delivered  is  actually  what  was  produced,  in  other  words,  a  well  thought 
out  and  detailed  quality  assurance  plan.  In  order  to  make  all  of  this  happen,  the  project 
manager  must  manage  all  of  the  stakeholders  and  identify  who  he  must  communicate  with, 
on  what  timeline,  and  to  what  detail.  These  three  supporting  pillars  are  those  that  cross  all 
projects,  allowing  the  project  manager  to  ensure  that  all  the  necessary  steps  have  been 
taken  to  achieve  the  end  goal  of  the  project.  Figure  2  provides  a  graphical  representation  of 
the  6  Pillars  of  Project  Management.  These  six  pillars  are  common  to  all  projects  and  span 
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across  the  project  life  cycle  and  are  supported  by  all  the  processes  within  PMI’s  identified 
five  process  groups. 


Figure  2.  6  Pillars  of  Project  Management 

PMI  (2013)  has  identified  42  process  areas  that  are  categorized  into  10  project  areas 
with  a  concentration  of  five  process  groups.  These  can  be  found  in  A  Guide  to  the  Project 
Management  Body  of  Knowledge  (PMBOK),  5th  Edition,  in  a  table  matrix;  however,  I  have 
included  the  below  diagram,  Figure  3,  from  the  PMBOK,  4th  Edition,  to  highlight  the  process 
areas  with  relation  to  the  three  foundational  pillars  of  scope,  cost,  and  time,  and  the  other 
three  integration  pillars  of  communications,  risk,  and  quality  management.  Procurement 
processes  are  not  necessarily  a  pillar  to  IPM  as  it  is  not  universally  applicable;  however, 
they  are  critical  to  the  cost  component  of  a  project  when  making  decisions  such  as 
make/buy  or  market  value.  The  integration  processes  are  those  that  cross  the  spectrum  of 
the  project’s  life  cycle  and  bring  the  integration  together. 

An  interesting  point  to  note  is  that  one  of  the  busiest  and  hardest  parts  of  being  a 
project  manager  is  in  the  planning  stage.  One  will  notice,  as  represented  in  Figure  3,  that 
there  is  more  process  area  development  and  initiation  in  the  planning  phase  of  the  project 
than  in  any  other  phase,  yet  it  seems  that  many  project  managers  never  spend  enough  time 
planning  their  projects  and  understanding  how  the  processes  are  interdependent  on  one 
another.  Through  a  thorough  understanding  of  IPM,  project  managers  can  better  visualize 
the  importance  of  proper  project  planning. 
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Figure  3.  Figure  Management  Processes 

(PMI,  2008) 

Let’s  explore  each  of  the  three  foundational  pillars,  scope,  time,  and  cost,  in  more 
detail.  As  seen  in  Figure  2,  all  three  are  critical  elements  in  the  planning  phase  of  the 
project. 

They  are  all  part  of  the  IPMP.  However,  before  one  can  consider  the  time  and  cost, 
one  must  fully  understand  the  requirements  behind  the  project.  Requirements  are 
represented  at  the  base  of  the  triangle  (Figure  2)  not  because  they  are  any  more  important 
than  any  other  aspect  of  the  project,  but  because  requirements  lay  the  true  foundation  for 
“Why  We  Are  Doing”  the  project.  Without  requirements,  there  is  no  basis  or  guidance  for 
executing  a  project. 

For  the  purpose  of  this  article,  we  consider  scope  and  requirements  as  interrelated; 
however,  there  are  some  slight  differences  within  the  definitions  in  that  scope  takes  into 
consideration  time  and  budget  as  well  as  the  deliverables.  Lewis  (1999)  suggested  that 
Performance  Level  (Requirements)  +  Budget  Constraints  (Cost)  +  Time  makes  up  the  scope 
of  a  project.  PMI  (2013)  defines  a  requirement  as  “a  condition  or  capability  that  is  required  to 
be  present  in  a  product,  service,  or  result  to  satisfy  a  contract  or  other  formally  imposed 
specification.”  Requirements  are  normally  provided  in  a  requirements  document.  At  times, 
requirements  documents  are  not  very  specific  which  in  turn  requires  the  project  manager 
working  with  the  project  team  and  the  customer  to  define  what  the  requirements  are  or 
determine  if  there  really  is  a  requirement  for  a  project.  It  is  important  to  note  that  not  all 
projects  will  have  clearly  defined  requirements  such  as  some  research  and  development 
projects  where  the  specifications  are  unknown  and  the  project  itself  is  to  help  drive  learning 
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to  move  forward.  These  are  often  high-risk  projects  where  the  real  deliverable  is  the 
knowledge  learned  from  executing  the  project. 

For  most  other  projects,  when  the  specification  is  unknown  but  a  specific  end  result 
is  needed,  the  project  manager  will  need  to  work  with  subject  matter  experts  to  help  identify 
“derived  requirements.”  In  defense  acquisition,  it  is  stated  that  “derived  requirements  are 
definitized  through  requirements  analysis  as  part  of  the  overall  systems  engineering  process 
(SEP)  and  are  part  of  the  allocated  baseline”  (Defense  Acquisition  University,  2012).  This 
implies  that  in  order  to  fully  comprehend  what  is  required,  we  need  to  understand  the  intent 
of  the  requirements  and  the  deliverables  needed  to  meet  those  requirements.  It  is  the  PM 
and  the  team’s  responsibility  to  work  with  the  end  users  to  define  the  requirements,  both 
those  that  are  known  and  those  that  are  derived.  Project  managers  should  use  a 
requirements  traceability  matrix  to  map  the  product  requirement  back  to  the  origin  that 
satisfies  the  customers’  needs  and  product  delivery.  Within  the  acquisition  community  this 
normally  goes  back  to  the  beginning  of  the  program’s  initiation  and  a  Mission  Needs 
Statement  that  is  developed  to  identify  a  warfighter  requirement.  They  may  not  know  exactly 
what  the  requirement  is,  but  they  can  articulate  the  need,  which  should  be  clearly  defined. 
This  process  is  cyclical  and  is  partially  depicted  in  the  fact  that  once  you  start  executing  the 
project,  the  execution,  planning,  and  monitoring  and  control  processes  all  overlap.  This 
iterative  process  may  drive  changes  to  your  project’s  scope  and  costs.  It  is  however  a 
necessary  process  since  requirements  and  requirements  definitions  are  critical  to  scope 
establishment,  control  of  scope  creep,  and  implementation  of  decision  analysis  and 
reporting,  that  supports  overall  control  of  the  project. 

In  Figure  3,  notice  that  the  green  boxes  relate  to  scope/requirements  which,  once 
collected,  determine  the  scope  of  the  work  needed.  As  Lewis  (1999)  indicated,  the  flow 
within  the  chart  would  have  one  realize  the  interdependence  on  cost  and  time.  In  order  to 
fully  understand  what  must  be  done,  the  project  requirements  need  to  be  broken  down  to  a 
level  where  work  definitions  or  work  packages  are  realized.  This  is  done  by  creating  a  Work 
Breakdown  Structure  (WBS).  The  WBS  is  defined  as  “a  hierarchical  decomposition  of  the 
total  scope  of  work  to  be  carried  out  by  the  project  team  to  accomplish  the  project  objectives 
and  create  the  required  deliverables”  (PMI,  2013).  In  essence,  we  are  taking  the  high  level 
requirements  and  separating  them  out  in  to  components  of  work  that  can  be  measured  and 
tracked.  Having  that  level  of  detail  allows  for  a  couple  of  things  to  happen.  First,  it  provides 
the  project  manager  with  a  good  understanding  of  the  level  of  detail  that  must  be  completed 
to  accomplish  specific  items  of  the  overall  project.  With  that  knowledge  in  hand,  the  project 
manager  can  then  calculate  a  good  bottoms-up  cost  estimate.  This  is  all  a  result  of  having 
the  finite  details  that  allows  the  project  manager  and  the  functional  SMEs  to  assess  the  level 
of  effort  required  to  complete  the  specified  tasks.  The  ability  to  break  a  project  down  to  what 
is  considered  a  work  package  level,  or,  as  Lewis  (1999)  stated,  “a  detailed  short-span  job  or 
material  item,  identified  by  the  contractor  for  accomplishing  work  required  to  complete  a 
contract.  Work  packages  are  discrete  tasks  that  have  specific  end  products  or  end  results.” 
In  other  words,  a  work  package  is  work  that  is  clearly  distinguishable  from  other  work  on  the 
project.  It  has  a  defined  timeframe  of  work  and  when  it  must  be  completed.  It  may  or  may 
not  have  milestones  to  be  measured,  depending  on  the  length/details  associated  with  the 
work  package,  and  it  has  the  ability  to  be  measured  for  success  of  work  performed.  The 
result  of  having  finite  requirement  details  is  a  bottoms-up  estimate  that  can  only  be  done 
with  the  knowledge  of  what  level  of  task  must  be  performed  and  by  what  skill  level  of  expert 
is  required  to  accomplish  the  work.  For  example,  one  would  not  want  an  apprentice  welder 
to  be  working  on  an  aircraft  frame  of  a  supersonic  jet;  instead,  an  expert  level  welder  would 
be  more  desirable  to  include  in  the  cost  element.  However,  that  apprentice  welder  may 
possess  the  necessary  skill  to  weld  the  support  arms  for  a  tray  rack  on  the  galley  lunch  line. 
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So,  now  that  a  work  breakdown  structure  has  been  established,  additional  parts  that  drive 
level  of  effort  work  can  be  added  in,  as  almost  every  project  has  some  level  of  effort  aspects 
tied  to  them.  The  end  result  is  a  sound  estimate  of  what  it  takes  on  the  surface  to  execute 
the  project,  that  is,  if  everything  works  perfectly.  But  what  about  risk  and  the  cost  of  risk? 
Those  are  factors  that  must  be  worked  and  then  reworked  into  a  project.  The  project 
manager  must  account  for  this;  however,  very  early  in  the  project  planning  phase,  project 
risk  has  only  been  minimally  assessed.  Therefore,  an  element  of  management  reserve 
needs  to  be  calculated  and  identified  as  such  for  risk  mitigation  and  contingency. 

At  this  point,  we  have  briefly  looked  at  two  of  the  core  pillars  of  project  management: 
requirements  and  defining  them  to  lower  levels  so  they  can  be  accurately  budgeted  for  and 
measured  for  quality.  Additionally,  we  have  looked  at  what  it  will  cost  to  execute  the  project 
by  identifying  the  lower  level  work  packages  that  roll  up  to  meet  requirements  and  their 
associated  cost.  Furthermore,  we  have  discussed  the  level  of  effort  costs  that  will  be 
assessed  to  make  sure  the  project  executes  properly.  However,  we  now  need  to  look  at  how 
we  actually  pull  it  all  together. 

The  project  manager  must  understand  the  interdependencies  between  the  elements 
within  the  work  breakdown  structure  and  the  sequence  in  which  those  elements  must  be 
executed.  The  third  core  pillar  to  project  management  is  to  develop  a  schedule  that  tells  the 
project  manager  whether  the  project  is  executing  as  expected,  if  it  is  behind,  or,  maybe, 
even  ahead  of  the  anticipated  timeline.  The  work  breakdown  structure  may  give  us  a  very 
good  idea  of  where  this  sequencing  may  start;  however,  interaction  with  the  functional 
subject  matter  experts  will  be  critical  to  the  proper  sequencing  of  activity.  This  sequencing  of 
activities  is  actually  the  establishment  of  a  project  schedule.  Many  project  managers  make 
the  mistake  of  thinking  that  once  they  have  the  items  within  their  project  sequenced,  they 
then  have  their  schedule.  The  truth  is  that  they  do  have  a  schedule,  but  they  do  not  have  a 
schedule  that  has  been  developed  for  implementation  of  an  integrated  project.  In  Figure  3, 
notice  that  the  project  schedule  has  many  factors  that  are  tied  directly  to  it  such  as  the 
budget.  If  we  reflect  back  to  Lewis’  definition,  each  of  these  finite  work  packages  has  a 
beginning  and  end,  and  they  also  have  specific  funding  attached  to  them  from  the  budget. 
This  budget  is  defined  from  several  other  supporting  processes  that  are  critical  to  define  the 
cost  of  each  of  the  work  packages.  An  example  would  be  the  human  resources  process: 
who  is  doing  the  work,  what  is  their  skill  level,  what  does  that  skill  level  cost,  and  so  forth. 

Is  there  risk  associated  with  the  specific  work  package?  Discussion  on  risk  will  come 
later,  but  for  now,  it  is  good  to  know  that  it  applies  to  the  schedule  and  cost.  We  mentioned 
earlier  that  every  work  package  has  a  quality  factor  to  it  as  well.  This  has  to  be  taken  into 
account  for  the  schedule.  Is  there  testing?  And  to  what  level?  Is  there  a  visual  inspection,  a 
bench  test,  or  maybe  regression  test?  These  all  must  be  considered  when  developing  an 
integrated  project  schedule.  We  can  deduce  that  sequencing  is  an  important  first  step,  but 
for  a  truly  integrated  schedule  other  aspects  must  be  considered  and  applied.  For  very  large 
projects  or  major  acquisition  programs,  this  schedule  definition  can  be  daunting  process,  but 
it  is  not  one  that  the  project  manager  should  attempt  alone.  It  takes  the  effort  of  all  the 
functional  area  leads — these  are  the  experts  in  their  field  that  lead  the  specific  areas,  such 
as  software  development,  hardware  integration,  and  so  forth.  Together  with  the  project 
manager,  this  collaborative  effort  is  paramount  to  flush  out  the  schedule,  by  defining  the 
requirements,  determination  of  make/buy,  time  constraints  imposed  by  the  customer,  budget 
availability,  and  so  forth.  If  a  system  is  being  developed  that  provides  a  capability  that  will 
modernize  the  efforts  of  the  end  user,  we  may  need  to  have  several  areas  that  must  be 
considered  and  included.  For  instance,  if  the  decision  was  made  to  completely  design  and 
develop  a  system  from  scratch  because  there  was  no  commercially  available  capability, 
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something  that  is  determined  during  an  analysis  of  alternatives,  we  will  need  to  identify  or 
build  the  hardware  for  the  system  (first  functional  area)  and  we  will  need  to  develop  the 
software  (second  functional  area).  Most  would  assume  that  those  are  the  only  two  areas  to 
consider;  however,  after  further  analysis,  several  other  functional  areas  must  be  taken  in  to 
account.  The  security  of  the  system  or  Information  Assurance  (third  functional  area)  must  be 
accounted  for,  as  well  as  the  logistics  aspects,  which  include  deployment,  documentation, 
and  sustainment  (fourth  functional  area).  We  briefly  discussed  quality  of  the  product,  but 
quality  goes  much  further  than  what  is  the  final  delivered  product.  Testing  throughout  the 
process  is  key  to  project  execution  and  quality  of  the  production;  quite  honestly  it  has  a 
secondary  benefit  in  keeping  cost  in  check  (fifth  functional  area).  Furthermore,  we  may  need 
to  have  an  integration  expert  or  other  specialized  aspects.  It  just  depends  on  the  project,  its 
size,  the  complexity,  and  the  scope  that  was  identified.  As  you  can  see,  developing  an 
integrated  project  schedule  can  be  a  daunting,  difficult  job,  but  it  is  a  critical  component  to 
project  execution. 

How  the  schedule  is  displayed  or  the  tool  that  is  used  to  create  it  is  really  not  that 
important.  What  is  important  when  developing  the  integrated  project  schedule  is  that  each  of 
the  tasks  listed  are  traceable  to  the  requirements,  the  effort  required  for  the  task,  the 
associated  start  and  stop  times,  the  interdependencies  of  those  tasks  with  their 
predecessors  and  successors,  and  the  resources  assigned  to  them  are  all  considered  and 
accounted  for.  As  depicted  in  Figure  4,  the  schedule  may  have  many  parts  to  it,  but  they  all 
must  have  a  common  start  and  finish  component.  There  may  be  a  documentation 
development  function  that  parallels  the  development  effort,  and  it  may  complete  well  before 
the  development  is  finished;  however,  the  end  result  will  be  to  deliver  the  product  to  the 
customer. 

The  aforementioned  example  depicts  five  functional  paths  for  the  project  execution, 
with  the  System  Engineering/Systems  Design  component  being  open.  In  this  section  you 
can  see  the  resources  that  are  assigned,  the  sequencing  of  the  tasks  and  how  they  are  all 
interrelated.  Once  the  project  schedule  has  been  laid  out,  the  critical  path  will  then  be  easily 
identifiable.  PMI  (2013)  defines  the  critical  path  as  “the  sequence  of  activities  that 
represents  the  longest  path  through  a  project,  which  determines  the  shortest  possible 
project  duration.”  Having  knowledge  of  the  critical  path  allows  the  project  manager  the 
peace  of  mind  to  know  where  there  is  room  for  float  or  slack  in  the  schedule,  allows  for 
necessary  resource  decisions,  and  most  importantly,  informs  the  project  manager  on 
whether  the  project  execution  is  moving  along  as  planned.  When  developing  an  integrated 
and  resource  loaded  schedule,  the  project  manager  will  be  able  to  quickly  identify  conflicts 
in  resource  allocation.  As  seen  in  Figure  4,  the  red  highlights  show  that  there  is  a  resource 
conflict  or  overutilization  of  a  resource.  With  this  knowledge,  the  project  manager  can  then 
use  methods  to  better  define  the  schedule  to  de-conflict  between  activities  within  the 
schedule.  There  may  be  a  need  to  identify  additional  resources,  or  use  additional  scheduling 
techniques  such  as  resource  leveling,  or  apply  critical  chain  method  scheduling.  It  is  evident 
that  there  can  be  considerable  effort  in  developing  an  integrated  schedule,  more  commonly 
referred  to  as  a  resource  loaded  schedule,  but  these  few  simple  examples  are  just  some 
basic  evidence  that  the  effort  allows  for  early  identification,  reduction  in  risk,  and  efficiency  in 
project  execution. 
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Now  that  we  have  looked  at  the  three  core  pillars  of  a  project,  we  understand  that 
requirements,  cost  (budget),  and  our  schedule  provide  the  solid  foundation  to  project 
execution  and  development,  be  it  a  product,  service,  or  event.  But  there  is  so  much  more. 
With  every  project,  as  in  life  itself,  risk  is  inherently  involved.  As  project  managers,  we 
cannot  afford  to  just  take  risk  by  chance.  Risk  crosses  every  phase  of  the  project  life  cycle, 
from  identification  of  stakeholders  in  project  initiation,  to  ensuring  we  properly  close-out  the 
project.  PMI  (2013)  identifies  risk  as  “an  uncertain  event  or  condition,  that  if  it  occurs,  has  a 
positive  or  negative  effect  on  one  or  more  project  objectives.”  We  commonly  focus  on  risk  as 
a  negative  aspect  when  we  talk  about  project  management,  but  it  is  important  to  understand 
that  risk  can  be  a  threat  (potential  negative  impact)  or  opportunity  (potential  positive  impact) 
to  the  project.  We  should  be  prepared  for  either  as  both  can  impact  project  execution; 
however,  we  need  to  realize  that  the  negative  effects  of  risk  have  a  far  greater  potential  to 
derail  our  efforts  and  therefore,  we  will  focus  on  what  we  should  do  and  how  risk  can  be 
handled. 

Bart  Jutte,  a  risk  management  expert  and  consultant,  categorized  the  10  Golden 
Rules  of  Project  Risk  Management  (2014).  Jutte’s  10  Golden  Rules  lay  a  foundation  that 
captures  the  essence  of  what  a  project  manager  and  the  team  needs  to  accomplish  to 
implement  an  effective  risk  management  plan  that  spans  the  life  cycle  of  a  project.  First,  risk 
management  should  always  be  a  part  of  the  project.  As  we  have  discussed,  risk 
management  is  so  important  to  the  project  as  it  forms  the  first  of  the  three  supporting  pillars 
as  identified  in  Figure  2.  Risk  has  the  potential  to  affect  the  project  from  the  very  beginning 
and  holds  through  until  the  project  is  closed. 

Jutte  (2014)  stated  that  the  project  must  start  identifying  risk  early  in  the  project.  All 
too  often,  the  project  manager  feels  pressure  to  immediately  start  work  and  haphazardly 
identifies  risks  as  they  rear  their  heads.  This  is  not  risk  management,  but  more  crisis 
reaction  management.  Early  identification  of  risk  allows  the  project  manager  the  ability  to 
project  ahead,  plan  for  mitigations,  or,  if  necessary,  implement  a  contingency  plan  should 
the  risk  be  realized. 

So  how  is  it  that  we  identify  these  threats  and  opportunities  to  the  project?  Who  is 
responsible  for  this  activity?  It  is  true  that  many  projects  have  a  risk  manager  assigned,  but 
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that  role  is  merely  to  administer  the  program,  track  the  risk,  and  advise  the  project  manager 
of  the  risk  status.  The  reality  is  that  no  one  person  on  a  project,  or  aligned  with  the  project, 
can  see  all  the  potential  risks.  Communication  must  happen  early  and  often  when  it  comes 
to  risk  identification,  management,  and  tracking.  Every  stakeholder  within  the  project  has  a 
vested  interest  in  the  performance  of  the  project  and  where  appropriate,  should  be  included 
in  the  risk  management  process.  Some  common  examples  of  stakeholders  are  as  resource 
sponsors,  customers  (Program  Executive  Office,  other  government  agencies),  development 
partners,  vendors,  and  end  users.  Stakeholder  risk  arises  from  the  fact  that  stakeholders 
may  not  have  the  inclination  or  the  capabilities  required  to  execute  the  project,  and  when  in 
a  capacity  to  direct  change,  it  can  have  a  devastating  impact  to  the  project.  Communication 
is  key  to  managing  stakeholders  which  will  be  discussed  later. 

Now  that  the  risks  have  been  identified,  we  have  the  first  step  of  this  cyclical  process 
started;  however,  it  is  not  enough  to  say,  “I’ve  identified  something  that  has  potential  to 
disrupt  what  our  team  is  doing.”  The  project  manager  and  the  team  must  analyze  the  risk. 
This  analysis  is  to  determine  the  likelihood  of  occurrence  and  the  impact  that  the  risk  will 
have  to  the  project.  There  are  many  ways  to  execute  the  risk  analysis,  but  regardless  of  the 
measure  used  to  make  the  determination  of  the  risk  factor,  there  are  still  several  steps  that 
must  be  carried  out.  The  risk  needs  to  be  categorized  into  a  grouping  that  can  be  tracked 
and  recorded.  We  need  to  determine  how  the  risk  will  be  handled.  Do  we  assume  the  risk 
and  watch  it  because  the  analysis  reveals  it  will  not  have  a  major  impact  to  the  project? 
Maybe  we  retain  the  risk  and  come  up  with  a  mitigation  strategy  and  contingency  plan. 
Perhaps  we  transfer  the  risk  to  another  party,  an  effective  strategy  when  the  project 
manager  and  his  team  may  not  have  technical  skills  that  the  risk  has  identified.  When  the 
risk  has  potential  catastrophic  effects,  another  strategy  is  to  merely  avoid  the  risk  completely 
and  turn  in  a  complete  different  direction.  Regardless  of  the  strategy,  someone  must  be 
assigned  the  ownership  of  the  risk.  This  is  often  a  subject  matter  expert  who  has  the 
expertise  to  understand  what  is  going  on  with  the  risk  and  track  it  throughout  until  it  is  either 
no  longer  a  risk  or  is  realized. 

Once  we  have  analyzed  and  identified  our  strategy  to  handle  the  risk,  we  need  to 
document  them  so  they  can  be  tracked,  which  is  normally  done  via  a  risk  register.  Again  the 
tool  that  is  used  is  immaterial  to  the  process;  the  importance  is  the  activity  and  the 
understanding  that  risk  identification,  analysis,  and  determination  of  action  and  ownership  is 
a  process  that  happens  throughout  the  life  of  the  project,  from  inception  through  closeout. 
More  importantly,  early  risk  analysis  has  an  impact  to  the  core  pillars  of  the  project;  cost, 
schedule,  and  performance. 

In  that  risk  has  the  potential  to  have  such  a  great  impact  to  a  project,  we  must 
determine  how  we  are  going  to  measure  risk  for  tracking.  In  many  cases,  we  can  use  the 
simple  qualitative  method  of  merely  classifying  it  as  high,  medium,  or  low.  This  is  based  on 
the  risk  factor  determined  when  analyzing  the  risk  and  having  an  understanding  of  the  cost 
of  the  mitigation  strategies.  However,  the  size  and  complexity  of  the  project  may  require  we 
use  a  quantitative  method  to  determine  the  potential  cost,  requiring  we  go  deeper  and 
capture  a  quantitative  analysis  of  the  risk  which  uses  measurable  and  objective  data  to 
determine  the  value  of  the  risk  and  the  mitigation  strategy.  This  is  done  through  probability 
and  regression  analysis  using  such  things  as  Monte  Carlo  simulations  and  the  use  of 
simulation  tools  like  Crystal  Ball  and  @Risk  which  fit  probability  distributions  to  the  data  set 
in  order  to  make  determinations  of  probabilities. 

Regardless  of  our  methodology,  we  want  to  capture  the  cost  of  the  risk  as  a  part  of 
our  integrated  project.  This  factor  is  then  captured  within  the  overall  cost  of  the  plan, 
integrating  the  risk  association  with  the  schedule.  This  seems  like  a  lot  of  effort  and  cost  on 
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what  appears  to  be  a  mostly  administrative  process;  however,  it  is  one  of  those  processes 
which  when  executed  from  the  onset  of  a  project,  actually  reduces  cost.  The  fact  that 
potential  threats  or  opportunities  to  the  project  are  identified  early  allows  for  the  necessary 
adjustments  before  they  become  so  big  that  they  cannot  be  dealt  with  and  become  an  issue. 
The  old  adage,  pay  me  now  or  pay  me  later,  is  really  the  case  when  it  comes  to  risk 
management. 

At  this  point  we  have  worked  to  establish  our  foundation  with  requirements,  identified 
the  cost  and  schedule  of  the  project  and  identified  threats  and  opportunities  in  our  project  by 
implementing  solid  risk  management.  This  is  a  solid  start,  but  how  do  we  know  that  what  we 
are  doing  will  deliver  the  quality  product  that  meets  the  requirements  we  set  out  to 
accomplish?  The  answer  lies  in  the  next  supporting  pillar  to  IPM,  Quality  Management. 

When  we  start  planning  our  project,  we  need  to  make  sure  we  build  in  quality  from 
the  beginning.  By  doing  this,  we  avoid  the  pitfalls  of  blindly  moving  forward  without  verifying 
that  what  we  are  doing  makes  sense  and  is  meeting  the  requirements.  PMI  (2013)  defines 
quality  as  “the  degree  to  which  a  set  of  inherent  characteristics  fulfills  requirements.”  By 
implementing  concrete  quality  assurance,  we  are  creating  a  planned  and  systematic  means 
that  will  assure  we  are  meeting  the  defined  standards,  practices,  and  procedures  that  are 
necessary  for  the  project  (Gallagher  et  al.,  201 1 ).  But  we  must  ensure  that  we  differentiate 
between  quality  assurance  and  quality  control.  All  too  often  these  terms  are  used 
interchangeably;  however,  they  are  not.  Quality  control  stresses  the  testing  of  the  project 
products  in  order  to  identify  defects  that  drive  decisions  by  management,  normally  through 
processes  like  decision  analysis  or  change  management.  The  defect  may  drive  a  decision  to 
halt  production  (development)  and  consider  other  factors.  On  the  other  hand,  quality 
assurance  endeavors  to  improve  and  stabilize  production  and  avoid,  or  minimize,  issues 
which  can  lead  to  the  defect(s). 

When  we  consider  the  scope  of  quality  management  planning,  we  understand  that  it 
identifies  the  quality  policies  and  procedures  applicable  to  the  project  for  both  project 
deliverables  and  project  processes.  Having  established  a  Quality  Management  Plan  means 
that  we  are  looking  at  the  total  project.  There  are  four  components  to  developing  a  Quality 
Management  Plan  as  outlined  in  a  study  at  Virginia  Tech  (2013):  quality  planning,  quality 
assurance,  quality  control,  and  independent  verification  and  validation. 

When  we  break  this  quality  management  down,  we  can  see  how  it  fits  directly  into 
the  life  cycle  of  a  project  and  thus  lives  up  to  being  a  pillar  of  project  management.  Project 
planning  is  normally  conducted  in  the  planning  phase  of  the  project  while  quality  assurance 
takes  place  during  project  execution.  Making  sure  we  have  the  right  processes  in  place 
supports  the  project  manager’s  ability  to  properly  execute  and  run  the  project.  Project 
control  is  an  integral  part  of  Project  Monitor  and  Control  because  as  we  move  through  our 
project,  we  must  measure  our  progress  to  identified  measurements  and  metrics.  Not  all 
projects  implement  the  fourth  element  of  the  quality  management  strategy  but  they  should. 
Independent  validation  and  verification  is  the  testing  and  reviews  that  provides  the  project 
manager  with  an  unbiased  independent  view  of  the  project  deliverables. 

Having  a  well-designed  quality  plan  means  that  we  have  been  forward  looking  to 
ensure  our  quality  plan  is  integrated.  Through  thoughtful  insight,  quality  processes, 
techniques,  and  strategies  will  be  executed,  with  identification  of  those  with  the  responsibility 
for  their  particular  quality  assignment.  By  implementing  the  necessary  quality  control  in  the 
project,  we  are  implementing  the  techniques  and  activities  to  ensure  we  are  fulfilling  the 
project’s  requirements.  As  stated,  quality  is  more  than  just  doing  testing  during  the  execution 
phase  of  the  project;  it  is  also  ensuring  we  have  the  necessary  processes  implemented  and 
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that  our  documentation  is  accurate  and  relevant  to  the  project.  For  example,  ensuring  that 
we  have  a  requirements  matrix  that  allows  us  to  trace  requirements  to  the  needs  statement 
and  then  validating  that  all  requirements  are  testable  and  have  the  appropriate  testing 
events  identified  against  them  is  critical  documentation  that  guides  the  project’s  success. 

The  sixth  and  final  pillar  to  project  management  is  the  one  that  is  overlooked  the 
most  often  yet  it  is  the  one  that  is  used  more  than  any  other:  communication.  When  you 
think  about  the  importance  of  just  about  anything  in  life,  communication  is  a  grounding 
element.  And  we  rarely  take  the  time  to  plan  our  communications  strategy  covering  the  who, 
how,  and  when  we  need  to  engage,  and  both  in  written  and  oral  formats.  Every  project  has 
many  communication  requirements.  The  stakeholders  that  we  have  identified  in  the  initiation 
phase  all  have  a  piece  of  the  project  action/responsibility.  We  have  to  have  a  plan  on  how  to 
communicate  with  them  and  how  to  manage  their  expectations.  At  times,  certain 
stakeholders  will  have  a  more  active  role  than  others;  regardless,  we  need  to  have  a 
communications  strategy  and  plan  in  place  that  guides  the  project’s  actions.  Obviously,  the 
size  and  complexity  as  with  all  processes  speaks  to  the  level  of  complexity  of  a 
communications  plan  we  need.  But  regardless,  a  strategy  is  needed  to  guide  how  we  will 
engage,  when  we  will  engage,  and  with  whom  we  will  engage,  on  what  area(s). 

One  of  the  most  important  aspects  of  a  communications  plan  is  establishing  a 
strategy  that  will  help  the  project  manager  and  team  manage  stakeholder  expectations. 
Managing  stakeholders  is  a  critical  part  of  project  management,  and  one  of  the  42  process 
areas  identified  by  PMI.  According  to  the  PMBOK  (2013),  stakeholder  identification  is  one  of 
two  process  areas  that  should  be  accomplished  in  the  initiating  phase  of  a  project,  and  a  key 
component  to  understanding  the  breadth  of  relationships  that  must  be  managed  and  to  what 
level  of  communication  will  be  required  to  manage  expectations,  independently  and  as  a 
group.  Depending  upon  the  complexity  of  the  project,  it  may  not  be  a  difficult  thing  to 
manage;  however,  in  large  complex  projects,  having  tools  to  help  manage  responsibilities 
and  interactions  provides  the  infrastructure  to  drive  to  success.  One  of  these  tools  is  a 
responsibility  assignment  matrix  (RAM). 

A  top  strategy  for  ensuring  cohesive  communications  within  a  project  and  integrating 
communications  across  the  life  cycle  is  to  establish  responsibilities  for  each  stakeholder.  A 
RAM  is  a  tool  that  allows  the  project  manager  to  understand  how  the  project  participants 
interact  with  the  activities  of  the  project,  based  on  the  work  breakdown  structure. 

Additionally,  it  provides  the  interaction  of  who  is  responsible  for,  consulted  with,  informed  of, 
or  needs  to  support  a  specific  activity.  For  example,  a  technical  expert  who  must  be 
consulted  on  several  activities  may  not  be  the  person  responsible  for  completing  the  activity, 
but  their  expertise  is  critical  as  a  consultant  providing  support,  or  the  management  approvals 
that  are  required  before  initiating  an  activity,  and  so  forth.  Using  a  RAM  can  be  very 
beneficial  in  ensuring  that  all  aspects  of  the  project  and  associated  tasks  and  responsibilities 
are  well  covered  before  you  actually  start  work  on  the  engagement. 

On  larger  projects,  RAMs  can  be  developed  at  various  levels.  For  example,  a 
high-level  RAM  can  define  what  a  project  team  group  or  unit  is  responsible 
for  within  each  component  of  the  Work  Breakdown  Structure  (WBS).  Lower 
level  RAMs  are  used  within  the  group  to  designate  roles,  responsibilities,  and 
levels  of  authority  for  specific  activities.  The  matrix  format  shows  all  activities 
associated  with  one  person  and  all  people  associated  with  one  activity.  (PMI, 
2013) 
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Having  this  level  of  understanding  helps  the  project  manager  not  only  manage  the 
internal  stakeholders,  but  also  provide  insight  into  who  is  doing  what  activity  and  where  to 
derive  information  to  be  able  to  update  external  stakeholders. 

Communications  is  so  fundamental,  and  managing  stakeholder  expectations  is  so 
critical  that  we  need  to  be  decisive  and  direct  in  how  we  go  about  ensuring  we  have  clear 
lines  of  communication  established.  Will  the  RAM  chart  provide  the  organization  needed  to 
ensure  this  clear  and  concise  communications  flow?  There  is  no  absolute  answer  to  this 
question;  some  plans  are  very  complex,  and  some  are  very  simple.  It  all  depends  on  the 
level  of  complexity  of  the  project  and  the  desire  for  documentation.  A  foundational  start 
though  is  to  identify  the  tasks  within  the  project  via  a  solid  project  plan  developed  using  a 
WBS,  and  then  identifying  those  stakeholders  that  are  important  to  each  of  the  tasks.  It  is 
also  important  to  identify  stakeholder’s  roles  within  the  project  and  the  specific  task  that  they 
impact  or  that  impact  them.  This  determination  is  captured  in  whether  they  are  responsible, 
consulted,  accountable,  or  informed  (RACI).  A  simple  layout  would  be  to  develop  a  RACI 
matrix  with  the  activities  on  the  vertical  axis,  a  direct  output  of  the  WBS,  and  the  horizontal 
axis  of  Team  Members/Stakeholders,  and  then  identifying  their  participation  level  (people- 
project  interaction)  within  the  matrix. 

There  are  many  categories  that  can  be  identified  for  the  people — project  interaction. 
Again,  this  will  be  determined  by  the  complexity  of  the  project.  According  to  Egeland  (201 0), 
some  additional  areas  that  can  be  identified  (not  all-inclusive)  are 

•  Document  reviewer 

•  Input  requested 

•  Must  be  notified 

•  Approval  required 

•  May  be  notified 

•  Support 

•  Participant 

•  Gate  reviewer 

The  RAM  can  be  a  valuable  communication  device  as  it  displays  the  project 
participants  and  their  implied  relationship  to  one  another  as  well  as  to  the  specific  areas 
within  the  project.  There  are  a  number  of  resources  available  on  the  Web  to  help  you 
develop  a  RAM  for  your  project. 

Table  1  is  an  example  from  a  PM-Tips  article,  “The  Responsibility  Assignment 
Matrix”  (Egeland,  2010).  The  matrix  is  simple  enough  to  understand  the  concept,  yet  allows 
you  to  get  the  feeling  that  you  can  define  in  detail  the  level  that  you  need. 
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Table  1.  Example  of  a  Responsibility  Assignment  Matrix 


Key:  R  =  Responsible.  S  =  Support  Required.  C  =  Must  Be  Consulted.  N  =  Must  Be  Notified.  A  =  Approval 
Required,  G  =  Gate  Reviewer 

The  key  across  the  bottom  of  the  matrix  brings  clarity  to  the  activity  level  of  the 
individual  as  it  relates  to  the  task.  The  tasks  are  broken  down  by  WBS  and  Activity  Name. 
Obviously,  the  more  complex  the  matrix,  the  more  critical  the  identification  key  becomes. 

So  we  have  explored  and  spent  a  lot  of  time  looking  at  the  6  Pillars  of  Project 
Management  and  why  they  are  so  important  to  the  development  of  a  truly  integrated  project 
plan.  We  understand  that  20  of  the  process  areas  of  project  management  are  actually  done 
in  the  project  planning  phase  of  the  project.  That  means  there  are  really  22  more  that  are 
done  in  the  execution  and  the  monitoring  and  control  phases  of  the  project,  the  area  where 
we  get  the  thing  done  that  we  set  out  to  do.  Of  these  22  processes  (including  the  two  from 
project  initiation),  eight  are  in  the  execution  phase,  10  in  the  monitoring  and  control  phase 
and  the  last  two  in  the  closeout  phase  of  the  project.  This  tells  us  something  critical  to 
project  management  and  why  we  need  to  spend  the  time  up  front  planning  for  the  project. 

Having  looked  at  the  planning  phase  of  IPM  and  the  importance  it  plays  is  critical. 
Once  the  project  manager  has  taken  the  time  and  made  the  effort  to  start  off  the  project  by 
establishing  the  framework  that  comprises  of  the  six  pillars  of  IPM,  the  project  can  move 
forward  into  execution  with  confidence.  With  a  comprehensive  understanding  of  what  the 
requirements  are,  the  level  of  expertise  needed  for  each  of  the  tasks,  the  associated  risk, 
and  how  we  will  measure  and  control  the  project,  the  project  manager  can  move  forward 
into  executing  the  project. 

The  integrated  project  plan  as  developed  provides  the  roadmap  for  the  execution  of 
the  project.  The  team  can  be  assembled  based  on  a  complete  understanding  of  the 
requirements,  the  skill  level  needed  to  produce  results  for  the  specific  tasks  that  will  occur, 
along  with  the  project’s  schedule  that  has  identified  the  development  flow  that  includes 
efforts  for  quality  control.  This  pre-planning  allows  for  effective  resource  utilization  and 
reduces  waste  in  manpower,  time,  procurement,  logistics  (to  include  documentation),  and 
product  use.  Having  this  level  of  detail  allows  for  project  execution  that  has  the  right 
personnel  in  place  at  the  right  time  in  the  schedule.  It  provides  the  necessary  insight  for 


ACQUISITION  RESEARCH  PROGRAM: 
CREATING  SYNERGY  FOR  INFORMED  CHANGE 


-177- 


procurement  of  products  that  minimizes  logistics  costs  and  sets  integration  timelines.  Couple 
this  with  early  and  continuous  risk  management,  and  we  are  able  to  track  our  progress  with 
levels  of  certainty  that  would  not  be  achievable  without  having  an  integrated  approach. 

The  Risk  Management  Plan  is  executed  continuously  throughout  the  project  life 
cycle.  Regular  risk  reviews  that  incorporate  key  project  leadership  allow  for  appropriate 
decision-making  to  make  the  project  as  economical  as  possible  while  still  meeting  the 
requirements  of  the  project.  When  risks  are  realized,  a  plan  has  been  laid  out  and  cost 
identified  so  the  project  team  is  prepared  to  deal  with  any  issue.  Because  there  was 
preplanning,  the  project  knows  how  to  move  forward  and  make  adjustments,  as  well  as 
communicate  with  the  stakeholders  that  are  appropriate  for  the  situation. 

Our  schedule  allows  our  quality  control  to  be  as  effective  as  possible.  The 
implementation  of  a  task  oriented  schedule  allows  for  application  of  testing  and  validation  of 
product,  service,  document,  and  so  on,  in  order  to  achieve  maximum  efficiency  and 
effectiveness.  Catching  defects  as  early  as  possible  is  always  much  more  cost  beneficial 
than  allowing  them  to  compile  and  then  identifying  them  when  it  is  time  to  deliver  the 
completed  product.  This  has  been  known  to  be  so  costly  that  entire  projects  have  been 
scrapped  as  the  recovery  was  insurmountable. 

So  what  is  it  that  provides  us  all  this  insight?  Monitoring  and  control.  As  noted  earlier, 
there  are  10  processes  within  the  monitoring  and  control  phase  of  the  project  life.  As 
previously  discussed,  when  developing  an  integrated  resource  loaded  schedule,  time  was 
allocated  to  build  into  those  activities  that  would  allow  the  project  manager  to  monitor  and 
control  the  project,  to  include  testing  and  reviews.  The  reviews  provide  a  milestone  time  to 
evaluate  the  project  to  determine  whether  the  project  has  met  the  expectations  desired  to 
continue  to  move  forward.  These  would  include  phase  reviews  (commonly  called  gate 
reviews),  as  outlined  in  Figure  1,  which  allows  the  project  to  move  from  initiation,  to 
planning,  to  execution,  to  closeout  with  the  knowledge  that  they  have  completed  the 
necessary  requirements  for  each  phase  of  the  project  life  cycle. 

Having  a  testing  and  review  plan  developed  and  integrated  in  the  project  plan 
provides  the  project  team  with  the  knowledge  of  how  they  are  progressing.  It  allows  them  to 
identify  defects  early,  make  necessary  adjustments,  or  apply  appropriate  fixes.  Additionally, 
it  provides  the  project  team  the  opportunity  to  identify  risk  early  and  review  risks  and 
mitigation  strategies  in  a  defined  process  throughout  the  project  life  cycle. 

Monitoring  and  control  provides  the  project  manager  the  ability  to  measure  how 
effective  his  project  is  executing.  With  an  IPMP  that  has  incorporated  the  6  Pillars  of  Project 
Management,  the  project  cost  can  be  tracked  in  concert  with  the  schedule  that  has  laid  out  a 
sequenced  approach  for  the  project  execution.  With  this  information  of  what  each  task 
takes,  the  resources  needed  (manpower  and  cost),  coupled  with  the  time  phasing, 
stakeholders  will  be  able  to  ascertain  how  effectively  the  project  is  being  executed  against 
both  budget  and  schedule.  And  with  some  certainty,  barring  any  unforeseen  scope  changes, 
an  estimate  at  completion  can  be  determined  at  almost  any  time  during  the  project’s  life. 

All  too  often,  a  project  is  deemed  to  be  in  the  final  stages  of  its  life  cycle — the 
development  has  been  completed,  the  product  has  been  delivered,  documents  have  been 
prepared,  and  the  project  has  completed  95%  of  the  WBS  items.  However,  one  important 
step  is  still  missing.  If  the  project  manager  has  taken  the  time  to  build  an  integrated  project 
plan,  it  is  known  that  the  project  must  be  closed  out.  This  is  a  much  abused  aspect  of  project 
management  but  one  that  is  highly  important.  Closing  out  the  project  affords  the  project 
manager  the  opportunity  to  help  the  organization  in  several  ways  that  will  support  its  future 
endeavors.  The  project  manager  must  capture  the  lessons  learned  and  succinctly  report  on 
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the  project  actions  providing  input  to  the  Organizational  Management  Repository.  This 
action  helps  the  organization  learn  from  both  successes  and  failures  experienced  and 
provides  insight  into  what  to  expect  in  similar  projects.  Additionally,  it  provides  actual  costs 
of  the  project.  Through  all  the  ups  and  downs,  having  the  complete  insight  allows  for  these 
actual  costs  to  be  used  for  analogous  cost  estimating  of  future  work  that  is  of  similar  nature. 

One  of  the  most  important  aspects  of  closing  out  a  project  is  determining  what  we  do 
with  our  personnel  who  have  diligently  and  devotedly  supported  the  project  effort.  Projects 
do  not  run  without  personnel,  and  they  are  the  greatest  and  most  valuable  asset.  Based  on 
our  task-based  plan,  we  have  been  tracking  and  executing  on  these  human  resource 
requirements  throughout  and  we  now  need  to  execute  the  final  moves  of  our  personnel.  This 
planning  ensures  no  surprises  and  a  smooth  transition. 

Finally,  we  must  close  the  books  on  the  project.  There  are  a  few  actions  that  must  be 
accomplished.  We  must  plan  to  close  out  our  contract  actions,  ensure  we  capture  all  the 
deliverables  and  provide  contractor  feedback,  and  rate  the  contractor  performance. 
Furthermore,  we  must  begin  to  close  the  financial  books,  something  commonly  forgotten, 
especially  if  we  are  still  waiting  for  contract  billings  to  clear  or  maybe  a  vendor  bill  is  still 
outstanding.  Our  efforts  must  be  to  fully  realize  these  last  minute  costs,  return  the  funds  that 
remain  that  are  unexecuted,  and  close  the  project  in  the  financial  system.  This,  too,  then 
becomes  a  repository  and  authoritative  record  of  the  financial  aspects  of  our  project  that  can 
display  all  of  the  financial  actions  taken. 

With  a  shrinking  defense  budget  yet  a  real  need  to  meet  the  warfighter  demand  for 
increased  capability,  the  defense  acquisition  community  needs  to  become  more  efficient  and 
effective,  not  only  in  program  management  where  the  president’s  budget  is  realized,  but 
also  within  the  project  management  for  those  non-program-of-record  efforts  being  executed. 
Whether  at  the  Echelon  2  or  Echelon  3  command  level,  realizing  the  importance  of 
implementing  the  most  cost  effective  and  transparent  project  management  is  critical.  This 
can  be  done  only  through  development  of  an  integrated  project  plan. 

As  you  can  see,  the  6  Pillars  of  Project  Management,  when  developed  with 
integration  in  mind,  provide  the  basis  to  build  a  solid  integrated  project  plan.  They  provide  a 
basis  for  making  the  project  effective  and  efficient,  meeting  the  goals  of  better  buying  power 
as  applied  to  execution  of  a  defense  acquisition  project.  They  provide  an  understanding  that 
everything  springs  from  the  foundation  of  requirements  that  are  traceable  and  testable  to  the 
warfighter  needs.  It  determines  a  cost  based  on  known  factors  of  time,  resources,  and 
applying  anticipated  cost  of  risk.  It  identifies  and  applies  appropriate  expertise  with  the 
necessary  skills  to  execute  the  tasks  that  have  been  identified  through  decomposition  of  the 
requirements.  Building  in  a  quality  control  plan,  which  is  phased  in  to  the  project  schedule, 
supports  early  identification  of  defects  and  allows  for  appropriate  reviews  that  are  designed 
to  meet  milestone  objectives.  Of  course  none  of  this  is  possible  without  the  project 
managers  pinning  everything  together  with  communications  that  are  well  thought-out  and 
designed  with  intent  and  purpose. 
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